Goal Decomposition and Scenario Analysis in Business Process Reengineering

This paper presents experiences in applying the goal decomposition and scenario analysis model in the context of Business Process Reengineering (BPR). The relationships of goals, scenarios, as well as the understanding and description of business processes are discussed. Different methods of goal refinement, and the application of scenarios to support this process of refining goals and roles are reviewed. A case study is presented which serves to exemplify and validate the process of using scenarios in refining business process descriptions. We tried deriving full scenarios for business processes, but obtaining them from the organization's prescriptive goals was difficult. Explanatory scenarios that justify descriptive goals are easier to obtain but are fragmentary. We conclude that both types of scenario and goal analysis are necessary for effective BPR. The need for technology support for this process is discussed and attention is given to future anticipated research in this area 1 I n t r o d u c t i o n Business Process Reengineering (BPR) attempts to avoid the penchant of automating existing processes or tasks in organizations in order to achieve efficiencies, and it attempts to question the reasons why specific processes and activities are linked together in support of a particular business entity [Smith93]. BPR models an organization's behavior so that we may better understand how to modify that behavior, and then develop the requirements for the needed automation to support that changed behavior. Hammer and Champy [Hammer93] suggest that BPR requires "discontinuous thinking" (abandoning outdated rules and business operations) or starting from a "clean slate" in order to achieve dramatic improvements in performance. BPR usually involves the automation of some activities in the overall process, or the redistribution of process-related responsibilities from people to software systems (or even physical devices). The requirements for a software system that support a reengineered process therefore, must be understood in the context of the goals of the BPR project. A less radical approach than Hammer and Champy's [Hammer93] 'clean slate' philosophy is to identify local inefficiencies in business processes, and recommend interventions to remove or mitigate them. In such cases of incremental automation, the requirements for systems still arise out of a process analysis and can only be understood as a response to an organizational need. Most system development falls somewhere on a spectrum between 'clean slate' and 'incremental improvement.' Smith and McKeen [Smith93] use the term business re-engineering to refer to the 'clean slate' philosophy, and the term process reengineering refers to incremental automation. We will use these two terms in the remainder of this paper. A critical factor in successful projects appears to be that developers not only understand what they are developing, but why [Conklin90, Potts94a]. In the context of business 1 Email: {anton,mike,potts}@c~.gatech.edu